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Unified Routing Requirements for IPng 
Status of this Memo 


This memo provides information for the Internet community. This memo 
does not specify an Internet standard of any kind. Distribution of 
this memo is unlimited. 


Abstract 


This document was submitted to the IETF IPng area in response to RFC 
1550. Publication of this document does not imply acceptance by the 
IPng area of any ideas expressed within. Comments should be 
submitted to the big-internet@munnari.oz.au mailing list. 


1. IPng Requirements 


The following list provides requirements on the IPng from the 
perspective of the Unified Routing Architecture, as describe in RFC 
1322. 


1. To provide scalable routing, IPng addressing must provide support 
for topologically significant address assignment. 


2. Since it is hard to predict how routing information will be 
aggregated, the IPng addressing structure should impose as few 
preconditions as possible on the number of levels in the hierarchy. 
Specifically, the number of levels must be allowed to be different 
at different parts in the hierarchy. Further, the levels must not 
be statically tied to particular parts (fields) in the addressing 
information. 


3. Hop-by-hop forwarding algorithm requires IPng to carry enough 
information in the Network Layer header to unambiguously determine 
a particular next hop. Unless mechanisms to compute 
context-sensitive forwarding tables and provide consistent 
forwarding are defined, the requirement assumes the presence of 
full hierarchical addresses. Therefore, IPng packet format must 
provide efficient determination of the full hierarchical 
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destination address. 


4. Hierarchical address assignment should not imply strictly 
hierarchical routing. Therefore, IPng should carry enough 
information to provide forwarding along both hierarchical and 
non-hierarchical routes. 


5. The IPng packet header should accommodate a "routing label" or 
"route ID". This label will be used to identify a particular FIB 
to be used for packet forwarding by each router. 


Two types of routing labels should be supported: "strong" and 
"weak". 


When a packet carries a "Strong" routing label and a router does 
not have a FIB with this label, the packet is discarded (and an 
error message is sent back to the source). 


When a packet carries a "weak" routing label and a router does not 
have a FIB with this label, the packet should be forwarded via a 
"default" FIB, i.e., according to the destination address. In 
addition, the packet should carry an indication that somewhere 
along the path the desired routing label was unavailable. 


6. IPng should provide a source routing mechanism with the following 
capabilities (i.e., flexibility): 


— Specification of either individual routers or collections of 
routers as the entities in the source route. 


- The option to indicate that two consecutive entities ina 
source route must share a common subnet in order for the 
source route to be valid. 


— Specification of the default behavior when the route to 
the next entry in the source route is unavailable: 


- The packet is discarded, or 
- The source route is ignored and the packet is forwarded based 


only on the destination address (and the packet header will 
indicate this action). 


A mechanism to verify the feasibility of a source route. 
Security Considerations 


Security issues are not discussed in this memo. 
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